One prior computer architecture technique to increase computer performance is the use of parallelism. One type of parallelism is "pipelining." Pipelined architecture treats each operation as a series of more primitive operations called stages that can be executed in parallel. One type of pipelining is the pipelining of the execution of instructions.
Pipelining poses special problems with respect to the handling of traps. Traps are caused by external interrupts or by exceptional conditions (also referred to as "exceptions") detected in programs. Traps cause the interruption of the normal program flow so that a special program known as a trap handler can be executed. Examples of exceptions include overflows, underflows, and inexact results.
If a trap occurs, instruction execution should be stopped at some point in time. The trap handler should then be executed. Instruction execution should then be resumed at some point in time.
In one prior technique, hardware interlocks are used so that additional operations are not permitted until it can be determined that no trap has occurred on previous operations. According to this technique, an instruction execution pipeline is stopped as soon as a trap occurs. After the trap is handled, the instruction stream is restarted at the point at which the trap occurred. One disadvantage of this technique, however, is that it reduces performance.
In another prior technique, once a trap is detected, all instructions still in the pipeline are executed. The results of the execution of those instructions are stored. Status information associated with each of those instructions is not stored, however. Pipelined instruction execution is then resumed starting with the next instruction that has not already been executed. In other words, the next instruction executed is an instruction that was not in the pipeline when the trap occurred. One disadvantage of this technique is that simply storing the results of the instructions still in the pipeline when the trap occurred and not the respective status information is not sufficient, given that those instructions could have caused further traps. Thus, traps could be lost if other exceptions would have been generated by those instructions. One might know that that one had a floating-point error, for example, but one might not know any other exceptions that also occurred. One prior way to overcome this problem is to have a mode bit in software. If the mode bit is set, then pipelining is not permitted. If the mode bit is zero, then pipelining is permitted. If the mode bit is set, however, the performance advantages of pipelining are lost. But if the mode bit is zero and pipelining is permitted, then traps might be lost during execution.
In another prior technique, the software visible state information for a particular operation is not updated until all operations preceding that particular operation are finished. For example, for multiple pipelines, assume that (1) the instruction in the first pipeline is a multiplication instruction A.rarw.B*C, which takes five clock cycles to complete and (2) the instruction in the second pipeline is an addition instruction X.rarw.X+Y, which takes one clock cycle to complete. If a trap occurs on the fifth clock of the first pipeline, one must avoid having updated the state information for the second pipeline. One prior way of accomplishing this is to provide a special bypass mechanism together with additional registers that store state information prior to updating such that only the state information prior to updating is visible. One disadvantage of this technique, however, is the requirement of additional hardware.
In yet another prior technique, software requires that all pipelined operations be finished before any traps are taken. One disadvantage of this technique is that one cannot restart an exception. With this technique, one does not get an exception until the pipeline is finished. One, however, will have done operations in the meantime that are not reexecutable. For example, if the first instruction is A.rarw.B*C and the second instruction is X.rarw.X+1, one cannot restart the pipeline after a trap given that the value of X has changed. Thus, this technique merely gives one an error message and does not allow one to restart the pipeline.